This commit adds a test demonstrating the current behaviour when a macro
defined in a module with the `#[macro_export]` is imported from the
module rather than the crate root.

This commit suggests importing a macro from the root of a crate as the
intent may have been to import a macro from the definition location that
was annotated with `#[macro_export]`.

This commit extends the suggestion to handle imports that are aliased to
another name.

This commit introduces more dirty span manipulation into the compiler
in order to handle the various edge cases in moving/renaming the macro
import so it is at the root of the import.

This commit removes the assumption that the start of a use statement
will always be on one line with a single space - which was silly in the
first place.

This commit changes the suggestion so that it is split into multiple
parts in an effort to reduce the impact the applied suggestion could
have on formatting.

…eta regression).

This is result of squashing two revert commits:

Revert "compile all crates under test w/ -Zemit-stack-sizes"

This reverts commit 7d365cf.

Revert "bootstrap: build compiler-builtins with -Z emit-stack-sizes"

This reverts commit 8b8488c.

…x, r=QuietMisdreavus

Apply resource-suffix to search-index and source-files scripts as well

Fixes rust-lang#59771.

r? @QuietMisdreavus

Suggest importing macros from the crate root

Fixes rust-lang#59764.

r? @estebank
cc @varkor

…mp, r=alexcrichton

Exclude profiler-generated symbols from MSVC __imp_-symbol workaround.

LLVM's profiling instrumentation adds a few symbols that are used by the profiler runtime. Since these show up as globals in the LLVM IR, the compiler generates `dllimport`-related `__imp_` stubs for them. This can lead to linker errors because the instrumentation symbols have weak linkage or are in a comdat section, but the `__imp_` stubs aren't.

Instead of trying to replicate the linkage/comdat setup for the stubs, this PR just excludes the profiler-related symbols from stub-generation since they aren't supposed to be referenced via `__declspec(dllimport)` anywhere anyway.

r? @alexcrichton

EDIT: I considered making this more general, i.e. inferring from the symbol name if it is a Rust symbol or not. But then I figured out that that would yield false negatives for `#[no_mangle]` et al, so I went with a blacklist approach.

…ramertj

Clean up handling of `-Z pgo-gen` commandline option.

This PR adapts the `-Z pgo-gen` flag to how Clang and GCC handle the corresponding `-fprofile-generate` flag. In particular, the flag now optionally takes a directory to place the profiling data in and allows to omit the argument (instead of having to pass an empty string).

…, r=QuietMisdreavus

Don't generate empty json variables

r? @rust-lang/rustdoc

…t-stack-sizes-gc-sections-ld-gold-bug, r=alexcrichton

Revert "compile crates under test w/ -Zemit-stack-sizes"

Revert PR rust-lang#59401 to fix issue rust-lang#59652 (a stable-to-beta regression).

This is result of squashing two revert commits:

Revert "compile all crates under test w/ -Zemit-stack-sizes"

This reverts commit 7d365cf.

Revert "bootstrap: build compiler-builtins with -Z emit-stack-sizes"

This reverts commit 8b8488c.

----

(My intention is that someone can re-add this code again later, either after the `ld.gold` issue itself is fixed, or with safe-guards to check whether `ld.gold` is in use and then issuing warnings about the problems here when they arise.)